home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Nov 90 / MacApp.Tech$ 11⁄16⁄90 / 2349-More Sharing-Nov90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  2.3 KB  |  52 lines  |  [TEXT/GEOL]
  1. Item    4135679                         10-Nov-90        10:24PST
  2.  
  3. From:   ALGER                           KPMG Peat Marwick, Jeff Alger,VCA
  4.  
  5. To:     GER.XSE0067                     Germany - Norbert Lindenberg,IDV
  6.  
  7. cc:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    More Sharing
  10.  
  11. Norbert,
  12.  
  13. I knew it couldn't be that simple.  You are right, having MacApp call your
  14. application back through polymorphic methods is an ugly problem.  However, I
  15. can at least dispose of one of your concerns.  If MacApp stubs reside in their
  16. own segment, the linker will never generate JSRs, but will always go through
  17. the jump table.  Your case c) - same-segment calls - is thus not a problem
  18. going from the app to MacApp.  In the sharable MacApp segments, one should
  19. force the linker to use jump table entries throughout, so we can easily prevent
  20. same-segment references within the MacApp segments.
  21.  
  22. There is a deeper problem in polymorphic dispatch than simply not knowing at
  23. link time what is polymorphic and what is not (we WILL know this from the
  24. application's side; the problem is the call-back from MacApp).  Class IDs -
  25. which are assigned by the linker - must be consistent for both application and
  26. library for the following:
  27.  
  28. • The application's polymorphic dispatch code.
  29. • The library's polymorphic dispatch code.
  30. • The class table, used by various clients like the debugging modules,
  31. instantiate-by-name, etc.
  32.  
  33. I don't know the details of how the linker assigns class IDs; if it is
  34. consistent enough, we can probably fool it into assigning the MacApp classes
  35. first in such a way that any given MacApp class will always have the right
  36. class ID.  This means not stripping out unused classes, which expands the size
  37. of the class table, but only as a function of the number of classes, not
  38. methods.  We also have to force the library to use the application's class
  39. table, not its own.
  40.  
  41. As to polymorphic call-backs from MacApp, this calls for a little more
  42. cogitation.  I don't think these problems are insurmountable, even without
  43. linker support, but it may turn out to not be worth the effort.  At a certain
  44. point, patching things furiously at run time becomes too dicey to justify.  It
  45. would also appear that there is going to be a run-time penalty to pay by
  46. forcing things to go through the jump table throughout the library.
  47.  
  48. I remain,
  49. Still waxing,
  50. Jeff Alger
  51.  
  52.